Mainframe computers are large, multi-processor computing devices able to perform thousands of tasks every second. International Business Machine Corporation (IBM) mainframes provide online transaction processing subsystems, such as Information Management System (IMS®), Time Sharing Option (TSO), and Customer Information Control System (CICS®) (IMS and CICS are registered trademarks of IBM), that enable high-speed transaction processing of data. Batch processes also entail transaction processing. Such subsystems often work with a database subsystem, such as the DB2® database from IBM.
Occasionally, the DB2 database may perform operations that require database objects, such as tables, table spaces, indexes, etc., to be taken offline temporarily. For example, changes to the structure of a table generally require that the table be offline for a short period of time to swap a shadow table having the new structure with the table having the old structure. In order to avoid causing transactions against the database to fail while the database is taken offline, some vendors offer an “online” outage process that allows transactions to be quiesced or suspended when the database object is taken offline temporarily. Such a period when the object is offline while transactions are suspended may be referred to as a drain. In order for a drain to be granted there can be no transactions running against the database object and no open protected threads for the database object that is being taken offline.
But problems exist with the current drain methods for online outage processes. First, transactions can come in at high rates. Thus, even if a drain takes 20 seconds, several hundred or even thousands of transactions may be suspended. Furthermore, the waiting transactions are held at the database subsystem and may take up many of the limited connections, or threads, used to process work in the database. Clearing out such a backlog of waiting transactions can take hours.
Another problem arises when threads are protected. Because there are costs associated with setting up a thread for a transaction, some transaction processing subsystems may designate a thread as protected. Protected threads are held open for a specified amount of time after a transaction completes. The protected thread can be associated with a transaction code, among other things. An incoming transaction may be eligible to run on the protected thread if the transaction has compatible properties. Because the thread is already open, the transaction can use the thread without incurring thread set up costs. Database resources held by protected threads are only released when the specified time elapses without a transaction using the thread. While this brings down operating costs absent a database outage, the protected threads may cause a drain request to wait or time out, lengthening the time that transactions are suspended, causing an even bigger backlog of waiting transactions. While currently running transactions may be terminated to prevent a drain request from timing out, this causes the transactions to fail and is disfavored by users.